Programming language design concepts

ion is a mode of thought by which we concentrate on general ideas rather than on specific manifestations of these ideas. Abstraction is the whole basis of philosophy and mathematics, and is also fruitful in many other disciplines, including computer science. In systems analysis, abstraction is the discipline by which we concentrate on essential aspects of the problem at hand, and ignore all inessential aspects. For example, in designing an air traffic control system we concentrate on details that are relevant to the working of the system (such as the aircraft’s type and call sign), and ignore the numerous irrelevant details (such as the aircraft’s color and external markings, the crew’s names, and the passengers’ names). In programming, abstraction alludes to the distinction we make between what a program unit does and how that program unit works. This enables a separation of concerns between the programmers who use the program unit and the programmer who implements it. Furthermore, we can use low-level program units to implement higher-level program units, and in turn use these to implement still higher-level program units. In fact, we can introduce as many levels of abstraction as desired. Separation of concerns and multiple levels of abstraction are essential tools in building large software systems. Procedural abstraction is concerned with the simplest program units, namely procedures. In this chapter we shall study: • proper procedures and function procedures; • parameters and arguments; • how procedure calls and parameters are implemented. In Chapter 6 we shall study methods, which are the counterparts of procedures in objectoriented languages. 5.1 Function procedures and proper procedures A procedure is an entity that embodies a computation. In particular, a function procedure embodies an expression to be evaluated, and a proper procedure embodies a command to be executed. The embodied computation is to be performed whenever the procedure is called. A procedure is often defined by one programmer (the implementer) and called by other programmers (the application programmers). These programmers have different viewpoints. The application programmers are concerned only with the procedure’s observable behavior, in other words the outcome of calling the procedure. The implementer is concernedwith how that outcome is to be achieved, in other words the choice of algorithm.